The Linux Kernel HOWTO: Patching the kernelNext Previous Contents 


7. Patching the kernel 
7.1 Applying a patch 
Incremental upgrades of the kernel are distributed as patches. For example, if 
you have version 1.1.45, and you notice that there's a `patch46.gz' out there 
for it, it means you can upgrade to version 1.1.46 through application of the 
patch. You might want to make a backup of the source tree first (`make clean' 
and then `cd /usr/src; tar zcvf old-tree.tar.gz linux' will make a compressed 
tar archive for you.). 
So, continuing with the example above, let's suppose that you have `patch46.gz' 
in /usr/src. cd to /usr/src and do a `zcat patch46.gz | patch -p0' (or `patch 
-p0 < patch46' if the patch isn't compressed). You'll see things whizz by (or 
flutter by, if your system is that slow) telling you that it is trying to apply 
hunks, and whether it succeeds or not. Usually, this action goes by too quickly 
for you to read, and you're not too sure whether it worked or not, so you might 
want to use the -s flag to patch, which tells patch to only report error 
messages (you don't get as much of the ``hey, my computer is actually doing 
something for a change!'' feeling, but you may prefer this..). To look for parts 
which might not have gone smoothly, cd to /usr/src/linux and look for files with 
a .rej extension. Some versions of patch (older versions which may have been 
compiled with on an inferior filesystem) leave the rejects with a # extension. 
You can use `find' to look for you; 
    find .  -name '*.rej' -print
prints all files who live in the current directory or any subdirectories with a 
.rej extension to the standard output. 
If everything went right, do a `make clean', `config', and `dep' as described in 
sections 3 and 4. 
There are quite a few options to the patch command. As mentioned above, patch -s 
will suppress all messages except the errors. If you keep your kernel source in 
some other place than /usr/src/linux, patch -p1 (in that directory) will patch 
things cleanly. Other patch options are well-documented in the manual page. 
7.2 If something goes wrong 
(Note: this section refers mostly to quite old kernels) 
The most frequent problem that used to arise was when a patch modified a file 
called `config.in' and it didn't look quite right, because you changed the 
options to suit your machine. This has been taken care of, but one still might 
encounter it with an older release. To fix it, look at the config.in.rej file, 
and see what remains of the original patch. The changes will typically be marked 
with `+' and `-' at the beginning of the line. Look at the lines surrounding it, 
and remember if they were set to `y' or `n'. Now, edit config.in, and change `y' 
to `n' and `n' to `y' when appropriate. Do a 
    patch -p0 < config.in.rej
and if it reports that it succeeded (no fails), then you can continue on with a 
configuration and compilation. The config.in.rej file will remain, but you can 
get delete it. 
If you encounter further problems, you might have installed a patch out of 
order. If patch says `previously applied patch detected: Assume -R?', you are 
probably trying to apply a patch which is below your current version number; if 
you answer `y', it will attempt to degrade your source, and will most likely 
fail; thus, you will need to get a whole new source tree (which might not have 
been such a bad idea in the first place). 
To back out (unapply) a patch, use `patch -R' on the original patch. 
The best thing to do when patches really turn out wrong is to start over again 
with a clean, out-of-the-box source tree (for example, from one of the 
linux-x.y.z.tar.gz files), and start again. 
7.3 Getting rid of the .orig files 
After just a few patches, the .orig files will start to pile up. For example, 
one 1.1.51 tree I had was once last cleaned out at 1.1.48. Removing the .orig 
files saved over a half a meg. 
    find .  -name '*.orig' -exec rm -f {} ';'
will take care of it for you. Versions of patch which use # for rejects use a 
tilde instead of .orig. 
There are better ways to get rid of the .orig files, which depend on GNU xargs: 
    find .  -name '*.orig' | xargs rm
or the ``quite secure but a little more verbose'' method: 
    find . -name '*.orig' -print0 | xargs --null rm --
7.4 Other patches 
There are other patches (I'll call them ``nonstandard'') than the ones Linus 
distributes. If you apply these, Linus' patches may not work correctly and 
you'll have to either back them out, fix the source or the patch, install a new 
source tree, or a combination of the above. This can become very frustrating, so 
if you do not want to modify the source (with the possibility of a very bad 
outcome), back out the nonstandard patches before applying Linus', or just 
install a new tree. Then, you can see if the nonstandard patches still work. If 
they don't, you are either stuck with an old kernel, playing with the patch or 
source to get it to work, or waiting (possibly begging) for a new version of the 
patch to come out. 
How common are the patches not in the standard distribution? You will probably 
hear of them. I used to use the noblink patch for my virtual consoles because I 
hate blinking cursors (This patch is (or at least was) frequently updated for 
new kernel releases.). With most newer device drivers being developed as 
loadable modules, though, the frequecy of ``nonstandard'' patches is decreasing 
significantly. 


Next Previous Contents 